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REMARKS 

Applicant has thoroughly considered the Office action mailed on November 30, 
2006. Claims 3, 5, 6, 9-13, 15-19, 21, 29, 30, and 32-37 are presented in the 
application for further examination. Reconsideration of the application claims in view of 
the following remarks is respectfully requested. 

Claim Rejections under 35 U.S.C. § 102 

Claims 5, 15, 19, 21, 29-30 and 32-37 stand rejected under 35 U.S.C. 102(e) as 
being anticipated by Chen et al., U.S. Pub. App. 2003/0191703 (Chen). Chen teaches 
a system for providing aggregated accounts information to an interested third party. 
The client is allowed to specify various levels of access permissions for an interested 
party to control the level of detail accessible to one or more interested parties. 
However, the client grants access by interested party and not the intended use of the 
information by the interested party. In particular, in paragraph 148, Chen discloses the 
client investor is allowed to "control or change the accounts, if any, that are accessible 
by a particular interested party using the data aggregation system." Furthermore, the 
client investor may choose "one or more interested parties, or interested party team, 
who may access client investment account information, as well as the option of 
specifying the level of detail available to each interested party." (Chen, pages 14- 
15, paragraph 148). Specifically, "the data aggregation system will only display a 
client's account data to an interested party if and when the client so allows." 
(Chen, pages 14-15, paragraph 148). Chen teaches that "[T]the methods and 
techniques by which the data aggregation system allows a client to manage access to 
his account information by interested parties is referred to herein as permissioning." 
(Chen, pages 14-15, paragraph 148). In other words, Chen teaches nothing more than 
allowing a client investor the ability to grant permission to one or more interested parties 
to access the client investor's aggregated accounts information and the permission is 
granted on the basis of who the interested party is and not the interested party's use of 
the information as recited in the claimed invention. 

In contrast, the present invention includes "generating an intended use request 
by the client of the certain user-specific information in the data store" and "comparing 
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the determined intended use request with the determined allowed level of access" as 
recited in claims 15 and 29. For example, suppose Joe goes to a financial web site 
which customizes the pages it displays to include the user's name and items of local 
financial news of interest to the user. (Specification, page 68, lines 13-14). After 
reviewing the options, Joe decides to subscribe to the financial advisor web site. 
(Specification, page 68, line 15). The site allows Joe to enter a series of stock symbols 
and industry types (e.g. tech sector) in which he is interested. (Specification, page 68, 
lines 16-17). The financial web site advisors will send Joe email when something of 
interest happens in any of the entered industry types. (Specification, page 68, lines 17- 
18). Additionally, the site will send an email alert to Joe when there are marked 
changes in the value of stocks listed in Joe's entered portfolio. (Specification, page 68, 
lines 18-19). After making his selections, Joe is asked to grant permission for the 
financial web site to contact him via email and alerts. (Specification, page 68, lines 20- 
21 ). The financial web site includes verbiage indicating that Joe agreeing to get email 
and alerts from the financial web site does not mean that the site will send him 
any other type of email or alert . (Specification, page 69, lines 21-23). Joe agrees 
and starts filling in the required information not available in his web-services. 
(Specification, page 68, lines 23-24). 

Accordingly, if something of interest has occurred in one of the industry types 
selected by Joe, the financial web site will send a query request against Joe's profile 
using the task ID and intentions for notifying Joe that something of interest occurred in a 
selected industry type. In this case, the financial web site will be allowed to access 
Joe's email address to send an email notifying Joe of the event. Now suppose the 
financial web site sends a query request against Joe's profile using the task ID and 
intentions for advertising. (Specification, page 68, lines 25-26). Because Joe has not 
allowed the site access to his email address for the intention of sending an 
advertisement, the consent system displays the information and intentions to Joe on a 
consent menu. (Specification, page 68, line 29-page 69, line 1). If Joe agrees, the 
consent system writes a financial web site specific role into Joe's profile access control 
list that includes the advertising intention. (Specification, page 69, lines 1-3). If Joe 
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does not agree, the financial web site will not be allowed to access Joe's email address 
to send the advertisement. 

Therefore, Joe not only specifies who (e.g., the financial web site) is allowed 
access to his personal information but the intention of the use of the information (e.g. 
when a sector has something interesting happening, when there are marked changes in 
the value of stocks listed in Joe's portfolio, or for targeting content and advertising). 
Furthermore, the permission is conditioned on the financial web site's intentions. From 
the example above, the financial web site can access Joe's email address when it 
intents to send Joe an email when a something interesting is happening within a 
selected industry sector. On the other hand, the financial web site can not access Joe's 
email address when it intents to send Joe an advertisement. 

Nothing in Chen teaches, suggests or makes obvious comparing the generated 
intended use request with the determined allowed level of access. The Examiner's 
reliance on paragraph 139 of Chen is misplaced; it teaches nothing more than providing 
the interested party with a list of client accounts accessible to the interested party if the 
interested party's identification/authentication information is valid. (Chen, page 14, 
paragraph 139). Thus, Chen fails to teach comparing the generated intended use 
request with the determined allowed level of access as recited in claims 15 and 29. 

Additionally, the present invention includes "invoking a consent engine in 
response to the client's request if the generated intended use request is outside the 
allowed level of access, said consent engine informing the user of the client's request to 
access the certain user-specific information in the data store and inviting the user to 
permit or to deny the client's request to access the certain user-specific information in 
the data store" as recited in claims 15 and 29. (Specification, page 19, lines 25-30). 

Nothing in Chen teaches, suggests or anticipates invoking a consent engine to 
inform the user of the client's request to access user-specific information and 
inviting the user to permit or to deny the client's request to access the information as 
recited in the claims. In fact, Chen teaches the away from such an approach. Chen 
discloses the list of potential interested parties are provided by the application server. 
(Chen, page 17, paragraph 175). Furthermore, Chen teaches the application server 
maintains and stores the list of potential interested parties "based upon the interested 
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parties previously entered or selected bv the client user for other aggregated 
accounts". (Chen, page 18, paragraph 176). 

For at least these reasons, Applicant submits that none of the cited references, 
alone or in combination, teach or anticipate each and every element of claims 15 and 
29. As such, the rejection of claims 15 and 29 under 35 U.S.C. § 102(e) should be 
removed. Additionally, claims 5, 19, 21, 30 and 32-37 depending from claims 15 and 29 
are allowable for at least the same reasons as claims 15 and 29. 

Claim Rejections under 35 U.S.C. § 103 

Claims 3, 10, 13 and 16-18 stand rejected under 35 U. S.C. 103(a) as being 
unpatentable over Chen, in view of Kramer et al., U.S. Pat. 5,414,852 (Kramer). 
Kramer discloses allowing application programs access to data objects using matching 
keys. In contrast to the present invention, Kramer fails to teach or disclose comparing 
the generated intended use request with the determined allowed level of access and 
invoking a consent engine in response to the client's request if the generated intended 
use request is outside the allowed level of access, informing the user of the client's 
request and inviting the user to permit or to deny the client's request, as recited by 
claims 15 and 19. Thus, the cited art, whether considered separately or together, fails 
to teach or suggest all of the claimed elements. Moreover, claims 3, 10, 13 and 16-18 
depend from claims 15 and 29 and are believed allowable for at least the same reasons 
as claims 15 and 29. Thus, the rejection should be withdrawn. 

Claim 6 stands rejected under 35 U.S.C. 103(a) as being unpatentable over 
Chen, in view of Ukelson, U.S. Pat. 6,338,096 (Ukelson). Ukelson teaches a micro web 
browser for transparently accessing multiple local and remote data stream types from 
an HTML browser. (Ukelson, abstract). In contrast to the present invention, Ukelson 
fails to teach or disclose comparing the generated intended use request with the 
determined allowed level of access and invoking a consent engine in response to the 
client's request if the generated intended use request is outside the allowed level of 
access, informing the user of the client's request and inviting the user to permit or to 
deny the client's request, as recited by claim 29. Thus, the cited art, whether 
considered separately or together, fails to teach or suggest all of the claimed elements. 
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Moreover, claim 6 depends from claim 29 and is believed allowable for at least the 
same reasons as claim 29. Thus, the rejection should be withdrawn. 

Claim 9 stands rejected under 35 U.S.C. 103(a) as being unpatentable over 
Chen, in view of Desai et al., U. S. Pat. 6,820,204 (Desai). Desai teaches that access to 
user profile information is granted on an element by element, user by user basis. (FIG. 
7; FIG. 9; FIG. 10; column 8, lines 62-65; column 9, lines 4-6). Furthermore, Desai 
teaches that access is granted based public/private key pairs. (Column 15, lines 26- 
30). Specifically, Desai discloses a record having the data element's universal ID and 
the user's ID is located in the key chain database. (FIG. 10, column 14, lines 65-67). If 
a matching record is found in the key chain database, then the encrypted secret key 
from the matching record is decrypted using the user's private key then the decrypted 
secret key is used to decrypt the requested data element. (FIG. 10, column 15, lines 8- 
12). In contrast to the present invention, Desai fails to teach or disclose comparing the 
generated intended use request with the determined allowed level of access and 
invoking a consent engine in response to the client's request if the generated intended 
use request is outside the allowed level of access, informing the user of the client's 
request and inviting the user to permit or to deny the client's request, as recited by claim 
29. Thus, the cited art, whether considered separately or together, fails to teach or 
suggest all of the claimed elements. Moreover, claim 9 depends from claim 29 and is 
believed allowable for at least the same reasons as claim 29. Thus, the rejection should 
be withdrawn. 

Claims 11-12 stand rejected under 35 U.S.C. 1 03(a) as being unpatentable over 
Chen and Kramer, in view of Erickson et al., U.S. Pub. 2003/0081791 (Erickson). 
Erickson teaches exchanges messages including encrypted data in the form of XML 
documents according to Simple Object Access Protocol. However, Erickson fails to 
teach or disclose comparing the generated intended use request with the generated 
allowed level of access and invoking a consent engine in response to the client's 
request if the generated intended use request is outside the allowed level of access, 
informing the user of the client's request and inviting the user to permit or to deny the 
client's request, as recited by claim 29. Thus, the cited art, whether considered 
separately or together, fails to teach or suggest all of the claimed elements. Moreover, 
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claims 1 1 and 12 depend from claim depend from claim 29 are believed allowable for at 
least the same reasons as claim 29 and the rejection should be withdrawn. 

CONCLUSION 

In view of the foregoing remarks, Applicant requests reconsideration and 
allowance of all pending claims. Applicant does not believe that a fee is due in 
connection with this response. If, however, the Commissioner determines that a fee is 
due, he is authorized to charge Deposit Account No. 19-1345. 

Respectfully submitted, 

/Frank R. Agovino/ 

Frank R. Agovino, Reg. No. 27,416 

SENNIGER POWERS 

One Metropolitan Square, 16th Floor 

St. Louis, Missouri 63102 

(314) 231-5400 

FRA/BAW/cjl 
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